-
Notifications
You must be signed in to change notification settings - Fork 230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exclude properties of type never
when emitting model schemas
#1127
Conversation
You can try these changes at https://cadlplayground.z22.web.core.windows.net/prs/1127/ Check the website changes at https://cadlwebsite.z1.web.core.windows.net/prs/1127/ |
@@ -1046,6 +1046,11 @@ function createOAPIEmitter(program: Program, options: ResolvedOpenAPI3EmitterOpt | |||
continue; | |||
} | |||
|
|||
if (isNeverType(prop.type)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if it would make sense to have this built at the checker level, like it doesn't even include the property in the model object then.
I guess the issue with it then is you can't project it if the property is not there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I think that's a good way to look at it. We might want to make the property have some other type in the future, so possibly better to leave it in at the checker level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we maybe open a design issue on this? It's also worth considering if failing that it would be good to put it in MetadataInfo.isPayloadProperty called just above. Upside, one fewer thing for an emitter that follows the (to-be-written, #1083) docs on metadata. Seems reasonable to say respond false to both isPayload and isMetadata for that. Speaking of which, do we need to handle @header something: never
, etc.?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is fine, just some thoughts for the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I will open a design issue for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I just opened #1128
This came up while working on https://github.com/Azure/cadl-azure/pull/2022#discussion_r984714147:
In some library authoring cases, it would be nice if a templated type could have a property that can be discarded when the
never
type is passed in. For example:This would enable spec authors to use
getOperationStatus
orgetOperationStatus<MyResultType>
without the need for two separate operation signatures. When theOperationStatus
type is emitted in OpenAPI, theresult
property will be elided whennever
is used in the operation signature.